Derive participants_count without participant join filter

When participantId is present, Conference.filter(**filters) introduces a join on participants constrained to that specific participant, and Count('participants', distinct=True) then counts only that filtered join row(s). In that path, participants_count no longer reflects the conference total (often returning 1), which regresses the participant-count chart for participant-scoped queries. This needs an aggregation that is independent of the request’s participant filter (e.g., a separate subquery over the M2M table).

Useful? React with 👍 / 👎.

Good approach. Annotations are the right call here.

One bug codex found: participants_count will be wrong when participantId is in the query string. Django reuses the filtered JOIN on the M2M table, so Count('participants') only counts the one filtered participant (returns 1 instead of the real total).

has_errors/has_warnings don't have this problem because Exists() runs its own subquery.

Claude suggested fix: use a subquery for the count too:

participants_count=Subquery(
    Participant.objects.filter(
        conferences=OuterRef('pk')
    ).order_by().values('conferences').annotate(
        cnt=Count('id', distinct=True)
    ).values('cnt')[:1],
    output_field=IntegerField(),
)

Exclude soft-deleted participants from participant counts

The participants_count subquery uses Participant.objects.filter(...), which bypasses the model’s Participant.filter(...) wrapper that enforces is_active=True. This means soft-deleted participants are still included in participants_count, so conference list metrics can be overstated after participant deletions. Previously, participant expansion paths used the wrapper and implicitly excluded inactive rows, so this changes API semantics for dashboards that rely on active participant totals.

Useful? React with 👍 / 👎.